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Abstract 

This  paper  specifies  a  systems  engineering  process  for  the 
development  of  federated  simulation  models  in  order  to  sup¬ 
port  systems-of-sy stems  analysis.  The  specification  borrows 
ideas  from  the  systems  engineering  domain,  the  simulation 
interoperability  domain,  and  the  software  engineering  do¬ 
main.  It  has  activities  on  the  operational  level  to  define  how 
the  real  system  operates,  the  system  level  to  define  the  over¬ 
all  architecture  of  the  federation,  and  the  technical  level  to 
fully  specify  requirement  to  model  developers.  Use  of  this 
process  allow  the  developers  of  federated  simulations  to  sep¬ 
arate  these  concerns  and  dialog  more  effectively  with  all  of 
these  groups. 

1.  INTRODUCTION 

The  requirement  for  a  systems  engineering  approach  to 
federation  development  stems  from  the  challenges  of  repre¬ 
senting  systems-of- systems  integration  in  a  simulation  envi¬ 
ronment.  Typically,  simulations  exist  that  represent  the  opera¬ 
tion  of  some  of  the  subsystems.  However,  when  these  subsys¬ 
tems  are  integrated  to  form  a  new  capability,  a  new  simulation 
model  is  often  useful  to  support  decision  making  and  opti¬ 
mization  with  respect  to  that  capability.  The  federation  simu¬ 
lation  developer  must  typically  rely  on  a  series  of  techniques 
from  other  disciplines  and  the  expertise  of  supporting  devel¬ 
opers  to  design  the  federation.  This  paper  outlines  a  systems 
engineering  approach  that  may  be  used  to  guide  the  process. 

2.  ENGINEERING  SKILLS  FOR  FEDER¬ 
ATED  SIMULATIONS 

This  paper  proposes  an  systems  engineering  process  to 
help  orchestrate  the  engineering  tasks  required  for  federated 
simulation  ||T|.  These  federates  must  be  held  together,  con¬ 
ceptually  and  technically,  by  the  engineering  capabilities: 

Information  Exchange  System.  The  capability  to  pass 
meaningful  information  between  federates  during  the 
simulation  run. 


Environmental  Representation.  The  capability  for  feder¬ 
ates  to  reference  a  shared  and  correlated  environment  in 
which  entities  interact. 

Entity  Representation.  The  capability  for  federates  to  refer¬ 
ence  shared  conceptually  aligned  information  about  en¬ 
tities  in  the  simulation.  Some  of  this  representation  is 
passed  via  the  information  exchange  system. 

Models.  Within  the  context  of  the  analysis  or  training  ques¬ 
tion,  the  internal  models  of  each  federate  must  be  vali¬ 
dated  and  coordinated  across  the  federation. 

Data  Collection.  The  capability  to  collect  meaningful  infor¬ 
mation  from  the  simulation  run  in  the  context  of  the  anal¬ 
ysis  question  or  training  objective  for  which  the  federa¬ 
tion  was  designed. 

3.  SUPPORTING  SPECIFICATIONS 

The  IEEE  Recommended  Practice  for  High  Level  Archi¬ 
tecture  (HLA)  Federation  Development  and  Execution  Pro¬ 
cess  (FEDEP)  is  an  existing  process  for  federation  develop¬ 
ment  j^.  However,  this  process  focuses  primarily  on  the  fed¬ 
eration  object  model  development  within  the  information  ex¬ 
change  system.  It  fails  to  address  coordination  of  the  other  re¬ 
quired  engineering  tasks.  A  more  comprehensive  systems  en¬ 
gineering  process  has  been  proposed  in  .  It  calls  for  a  com¬ 
mon  definition  of  requirements  via  the  Military  Missions  and 
Means  framework  0.  It  then  goes  on  to  call  for  further  pro¬ 
cess  of  information  exchange  system  development  and  anal¬ 
ysis  support  using  Model  Driven  Architectures  0.  However, 
that  process  assumed  the  federation  supported  military  sys¬ 
tems  analysis.  This  paper  extends  that  work  to  further  specify 
a  more  general  and  more  formal  systems  engineering  process 
that  supports  development  of  federated  simulations. 

Building  federations  requires  more  than  a  simple  technical 
understanding  of  how  simulations  exchange  data.  It  requires 
a  common  shared  conceptual  understanding  of  the  simula¬ 
tion  environment,  entities  in  the  models,  and  exchanges  be¬ 
tween  them.  It  is  very  difficult  to  gain  this  by  simply  looking 
at  source  code  and  conforming  to  technical  standards.  Lev¬ 
els  of  interoperability  shed  some  light  on  this  challenge  0. 
For  example,  technical  interoperability  is  a  very  specific  set 
of  protocols  that  clearly  define  the  standards.  Conceptual  in¬ 
teroperability,  on  the  highest  level,  is  a  loosely  defined  by 
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shared  concept  that  provides  context  and  common  organiza¬ 
tional  uses  for  the  models.  For  composable  models,  the  devel¬ 
opment  team  must  have  this  shared  conceptual  model  prior  to 
detailed  engineering  of  the  federation. 

Fortunately,  the  software  engineering  community  has  de¬ 
fined  a  framework  to  support  this  level  of  interoperability. 
The  Object  Management  Group’s  Model  Driven  Architecture 
(MDA)  is  an  open  standard  that  enables  an  organization  to 
specify  their  domain  expertise  in  a  modeling  language  that  is 
independent  of  the  technology  used  to  implement  that  logic 
Q.  This  specification  achieves  the  technical  goal  of  abstract¬ 
ing  the  domain  logic  away  from  the  technical  implementation 
details.  For  a  simulation  model,  this  supports  validation  of  the 
model  by  domain  experts  to  enable  composability. 

The  underlying  idea  is  to  separate  business  and  applica¬ 
tion  logic  from  underlying  technology.  To  enable  this,  MDA 
defines  artifacts  based  on  the  Unified  Modeling  Language 
(UML)  to  describe  a  hierarchy  of  models  that  cope  with 
the  various  challenges  on  different  levels.  Guidelines  for  the 
use  of  MDA  establish  three  different  modeling  viewpoints 
Q,  and  these  can  be  interpreted  for  the  simulation  domain. 
The  highest  level  of  abstraction  is  the  Computer  Independent 
Models  (CIM)  which  focus  on  the  system’s  business  logic. 
The  Platform  Independent  Models  (PIM)  capture  concepts 
and  processes  in  software  engineering  artifacts.  If  this  con¬ 
ceptual  model  is  mapped  to  a  concrete  platform  and  imple¬ 
menting  architecture,  the  result  is  a  Platform  Specific  Model 
(PSM).  In  the  optimal  case,  the  PSM  can  be  used  to  produce 
code,  as  all  information  needed  is  available. 

MDA  has  the  additional  advantage  of  standardized  meta¬ 
models.  The  Meta-Object  Facility  (MOF)|[^  and  XML  Meta¬ 
data  Interchange  (XMI)||^  declare  abstractions  for  the  repre¬ 
sentation  and  exchange  of  models.  These  features  of  MDA, 
if  applied  for  modeling  and  simulation,  allow  simulation  sys¬ 
tem  developers  to  take  advantage  of  the  numerous  modeling 
and  development  tools  that  are  available  in  the  commercial 
and  open  source  community  based  on  these  standards. 

4.  SYSTEMS  ENGINEERING  PROCESS 
FOR  DEVELOPMENT  OF  FEDERATED 
SIMULATIONS 

The  real  challenge  of  simulation  development  is  to  ensure 
that  the  final  product  is  consistent  with  the  purposes  for  which 
the  simulation  project  was  originally  started.  It  should  support 
analysis  of  different  strategies,  represented  as  simulation  in¬ 
puts.  In  so  doing,  there  must  be  a  mechanism  for  tying  differ¬ 
ent  simulation  development  activities  to  the  requirements  for 
certain  system  functions  to  be  modeled  and  to  certain  outputs 
to  be  produced.  A  systems  engineering  approach  to  simula¬ 
tion  development  ensures  that  these  ties  to  requirements  are 
maintained  throughout  the  process. 

The  process  borrows  from  the  Model  Driven  Architectures 


approach  to  produce  models  of  the  simulation  system  on  three 
different  levels  — targeting  three  different  sets  of  stakehold¬ 
ers.  Operational  level  activities  produce  an  operational  de¬ 
scription  of  the  system  to  be  simulated.  The  operational  prod¬ 
ucts,  analogous  to  the  CIM  of  MDA,  are  independent  of  the 
fact  that  a  simulation  model  is  being  built.  They  consider  the 
concerns  of  the  operational  stakeholders  who  must  use  or  op¬ 
erate  the  system  as  it  functions  in  the  real  world.  The  sys¬ 
tem  level  activities  focus  on  the  simulation  architecture  as  a 
whole.  These  products,  analogous  to  the  PIM  of  MDA,  as¬ 
sign  simulation  functions  and  metrics  to  different  simulation 
models.  The  primary  stakeholder  for  system  level  activities 
are  integration  engineers  and  managers  for  each  of  the  com¬ 
ponent  models.  The  technical  level  activities  focus  on  the  de¬ 
tailed  development  of  simulation  components  and  the  inter¬ 
faces  between  them.  These  products,  analogous  to  the  PSM 
of  MDA,  provide  sufficient  detail  for  software  engineers  to 
develop  code  that  will  interface  with  the  overall  simulation 
federation  to  provide  the  required  results.  In  some  cases,  the 
software  or  test  cases  may  be  auto-generated  from  the  techni¬ 
cal  specification. 

4.1.  Operational  Level  Activities 

In  performing  the  operational  level  activities,  simulation 
engineers  are  focused  on  the  problem  definition  phase  of  the 
systems  engineering  process  (D-  Their  primary  goal  during 
this  phase  is  to  gain  an  understanding,  documented  as  a  com¬ 
bination  of  UML  specifications  and  other  diagrams,  of  the 
system  to  be  modeled.  They  should  understand  its  users,  its 
functions,  and  the  value  derived  from  the  operation  of  the  sys¬ 
tem  itself.  The  steps  in  Figure  represent  the  steps  of  this 
process. 

Identify  system  use-cases.  Identify  how  the  system  is  used 
by  different  classes  of  users  to  perform  the  function  for 
which  it  was  designed.  This  results  in  a  high  level  UML 
use-case  model  for  the  system. 

Functionally  define  the  system.  Use  the  use-case  model 
and  work  with  system  users  to  define  in  a  hierarchy  the 
functions  of  interest  for  the  system.  This  results  in  a 
functional  hierarchy  for  the  system.  Figure  shows  this 
for  the  ground  soldier  command  and  control  system. 

Identify  stakeholders.  Identify  stakeholders  for  the  system. 
These  are  not  only  users,  but  also  system  owners,  system 
developers,  and  the  client  for  which  the  simulation  study 
is  being  performed.  Ensure  the  modeling  detail  captures 
enough  information  to  answer  the  question  at  hand  with¬ 
out  incorporating  so  much  detail  that  simulation  devel¬ 
opment  becomes  overly  difficult,  expensive,  and  time 
consuming. 


Systems  Engineering  Activities 


Engineering  Products 


Figure  1:  Operational  level  activities. 


Figure  2:  Functional  decomposition  for  ground  soldier  com¬ 
mand  and  control  system. 

Elicit  stakeholder  concerns.  Using  any  combination  of  in¬ 
terviews,  focus  groups,  and  surveys,  determine  the  fun¬ 
damental  concerns  and  values  of  the  stakeholders  iden¬ 
tified  in  the  previous  steps. 

Determine  system  objectives.  Based  on  the  functional  anal¬ 


ysis  and  stakeholder  concerns,  determine  the  system  ob¬ 
jectives  that  must  be  successfully  met  in  order  to  deliver 
value  back  to  the  stakeholders. 

Define  value  measures.  Once  the  objectives  have  been  iden¬ 
tified,  determine  value  measures  that  can  be  used  to  see 
if  the  system  has  indeed  met  those  objectives.  The  simu¬ 
lation  system,  once  developed,  must  be  able  to  estimate 
system  performance  in  terms  of  these  objectives  so  that 
the  relative  performance  of  different  alternatives  can  be 
determined.  The  results  of  this  phase  may  be  represented 
as  a  value  hierarchy  specified  as  a  UML  class  diagram 
where  each  value  measure  is  a  component  of  an  individ¬ 
ual  objective,  and  individual  objectives  are  components 
of  the  overall  system  objective.  It  is  also  helpful  to  spec¬ 
ify  the  range  of  possible  values,  from  least  desirable  to 
most  desirable,  for  each  performance  measure  |TQ|.  Fig¬ 
ure  shows  a  portion  of  the  value  hierarchy  for  a  ground 
soldier  command  and  control  system. 

Build  system  value  function.  A  simple  value  hierarchy  is 
not  sufficient  for  direct  comparison  between  alternatives. 
The  development  team  must  return  to  the  stakeholders 
and  determine  the  value  curves  and  weights  for  each  per¬ 
formance  measure,  taking  into  consideration  the  impor¬ 
tance  and  overall  variability  of  each  measure  fTQ|.  This 
results  in  a  value  function  that  translates  a  set  of  perfor¬ 
mance  scores  for  each  alternative  into  an  overall  value 
score  that  represents  the  value  of  that  alternative  to  the 
system  stakeholders. 

Construct  operational  scenarios.  Once  the  system,  its 


Figure  3:  Value  hierarchy  for  ground  soldier  command  and 
control  system. 


functions,  and  its  values  have  been  defined,  the  sim¬ 
ulation  study  team  must  also  define  the  scenario  that 
represents  the  context  for  evaluation  of  system  perfor¬ 
mance.  In  a  military  simulation,  this  represents  details 
such  as  terrain  and  weather,  forces  in  the  engagement, 
supporting  friendly  forces,  and  full  definitions  of  the 
entities  in  the  simulation.  The  scenario  definition 
describes  the  mission,  forces  involved,  and  roles  of  the 
simulated  entities.  In  a  military  context,  the  Military 
Scenario  Definition  Language  is  an  excellent  standard 
for  this  representation  (H). 

Entity  definitions  are  an  important  aspect  of  scenario 
definition.  All  too  often,  the  names  of  entities  can  lead  to 
ambiguous  understandings  of  the  actual  capabilities  rep¬ 
resented.  Entity  definitions  should  be  as  specific  as  pos¬ 
sible  with  references  to  authoritative  sources  that  pro¬ 
vide  accurate  data  to  simulation  modelers  who  must  rep¬ 
resent  these  entities  in  their  respective  simulations. 

Einally,  within  the  scenario,  the  functions  performed  by 
the  system  under  study  should  be  defined  as  a  functional 
fiow  model  so  that  simulated  events  can  be  synchro¬ 
nized  in  the  proper  order.  This  model  can  be  represented 
as  a  UML  activity  diagram.  A  portion  of  the  function 
fiow  model  for  the  artillery  fires  request  function  of  the 
ground  soldier  command  and  control  system  is  shown  in 
Eigure]^ 


Eigure  4:  Eunctional  fiow  model  for  request  artillery  fires 
function  of  ground  soldier  command  and  control  system. 

4.2.  Systems  Level  Activities 

Once  the  operational  picture  is  well  understood  and  doc¬ 
umented,  it  is  time  for  the  high  level  systems  design  of  the 
federated  simulation.  The  design  steps  in  this  phase  build 
UML  specifications  of  the  simulation  functions,  simulation 
data  collection,  information  exchanges,  and  environmental 
data.  These  steps  result  in  a  logical  allocation  of  functionality 
and  information  exchanges  that  derive  from  the  operational 
requirements  from  the  previous  step.  While  not  sufficient  for 
writing  code,  these  models  allow  simulation  engineers  and 
software  engineers  from  the  participating  federates  to  allo¬ 
cate  high  level  tasks  and  work  packages  to  support  simulation 
development. 

Select  participating  simulations.  Once  the  required  func¬ 
tionality  is  known,  the  simulation  engineers  must  re¬ 
search  candidate  federates  for  inclusion  in  the  federa¬ 
tion.  Some  of  the  considerations  for  selection  are  the  ca¬ 
pability  to  model  desired  phenomena,  ease  of  integration 
with  the  other  models,  and  difficulty  of  required  modifi¬ 
cations.  In  some  cases,  a  new  federate  must  be  developed 
in  order  to  model  some  aspects  of  the  system. 

Allocate  simulation  activities  to  specific  simulation  models. 

Once  the  candidate  federates  are  selected,  modeling 
functions  must  be  allocated  to  individual  federates. 


Figure  5:  System  level  activities. 


The  resulting  functional  allocation  takes  the  functional 
flow  diagram  from  the  operational  level  and  allocates 
speciflc  functions  to  federates  using  swim  lanes  in  the 
UML  activity  diagram.  A  portion  of  this  allocation  for 
the  ground  soldier  command  and  control  simulation  is 
shown  in  Figure 

Allocate  value  measures  to  specific  simulation  models. 

In  a  manner  similar  to  the  allocation  of  functions,  the 
requirements  to  collect  necessary  performance  data 
should  be  allocated  to  federates  as  well.  In  some  cases, 
the  required  data  may  not  exist  in  any  one  federate,  but 
will  have  to  be  collected  from  network  interaction  data 
collected  by  loggers. 

Define  simulation  modeling  functional  requirements. 

Once  the  modeling  functions  and  data  collection  func¬ 
tions  have  been  determined,  the  simulation  functionality 
requirements  may  be  formally  specified  for  the  models. 
These  requirements  documents  may  be  used  to  support 
contracting  with  federate  developers  who  must  deliver 
models  with  the  required  functions. 

Determine  information  exchange  requirements.  In  order 
for  the  federation  to  execute,  data  must  be  exchanged 
between  the  models.  These  requirements  may  be  derived 
from  the  activity  diagrams  used  to  allocate  functions  to 
individual  federates.  Any  time  that  a  control  line  crosses 


a  swimlane,  there  is  typically  a  requirement  for  some 
amount  of  information  to  be  passed  in  order  to  support 
that  allocation. 

Define  logical  data  model  for  information  exchange.  As 

information  exchange  requirements  are  identified  in 
the  previous  step,  engineers  must  formally  specify  the 
data  elements  required  to  support  that  data  exchange. 
These  data  requirements  can  often  be  specified  in  a 
UML  class  diagram.  This  is  a  two-way  process.  It  may 
be  more  efficient  to  delay  this  formal  specification  until 
the  information  exchange  architecture  is  selected  in  the 
technical  view.  In  some  cases,  information  elements 
from  that  architecture  may  be  reverse  engineered  to 
provide  the  require  information  elements. 

Build  entity  source  data.  In  addition  to  developing  simula¬ 
tion  software,  the  team  must  also  consider  the  entities 
that  will  participate  in  the  scenario.  In  some  cases,  these 
entities  must  be  constructed  from  a  significant  amount  of 
data.  This  step  represents  the  collection  of  accurate  and 
appropriate  source  data  for  the  entities  in  the  scenario. 

Build  environmental  source  data  In  addition  to  entities, 
the  environment  must  be  considered  as  well.  This  step 
represents  the  collection  of  source  data  necessary  to 
appropriately  represent  the  environment  in  the  differ¬ 
ent  federates.  The  environmental  representation  may  not 


be  the  same  for  all  federates.  However,  using  the  same 
source  data  will  lead  to  correlated  representations  across 
the  models. 

Once  the  system  has  been  designed  and  data  has  been  col¬ 
lected,  it  is  still  necessary  to  do  system  development  for  all  of 
the  participating  federates  and  for  the  overall  federation  in¬ 
tegration  architecture.  There  are  all  technical  level  activities 
that  look  to  provide  software  engineers  and  programmers  suf¬ 
ficient  information  that  will  allow  them  to  write  code  and  de¬ 
liver  working  federates  within  the  overall  specification.  Fig¬ 
ure  |7]  shows  a  diagram  of  the  technical  level  activities  and 
products. 

Select  information  exchange  technical  architecture.  The 

simulation  must  exchange  information  across  an  archi¬ 
tecture  designed  for  this  purpose.  Simulation  standards 
such  as  Distributed  Interactive  Simulation  (DIS)  or  the 
High  Level  Architecture  (HLA)  are  possible  choices. 
Another  possibility  is  to  use  service  oriented  archi¬ 
tectures,  based  on  web  standards,  designed  to  support 
business  or  industrial  systems. 

Develop  information  exchange  data  model.  The  informa¬ 
tion  exchange  data  model  must  be  specified  and  repre¬ 
sented  in  technical  format  selected  in  the  previous  step. 
In  the  case  of  HLA,  this  specification  will  be  a  federa¬ 
tion  object  model  (FOM).  A  web  services  architecture 
would  require  extensible  markup  language  (XML)  rep¬ 
resentations  of  the  data.  Once  the  information  exchange 
data  model  is  developed,  a  UML  sequence  diagram  can 
be  used  to  translate  simulation  functions  into  sequence 
diagrams  that  explicitly  show  the  communications  be¬ 
tween  federates  and  the  simulation  functions  performed 
by  each.  Figure  shows  a  sequence  diagram  for  the 
communication  function  of  the  ground  soldier  command 
and  control  federation. 

Specify  simulation  models.  Required  simulation  functions 
were  determined  as  a  systems  level  activity.  Now  these 
function  must  be  specified  using  the  language  and  for¬ 
mat  of  the  information  exchange  architecture.  For  ex¬ 
ample,  in  HLA,  certain  simulation  functions  could  be 
started  upon  receipt  of  specific  interactions  from  the  run¬ 
time  infrastructure  (RTI).  In  a  web  services  integration, 
these  functions  could  be  represented  using  the  web  ser¬ 
vices  definition  language  (WSDL). 

Build  entity  data  models  in  simulation  specific  formats. 

In  this  step,  the  entity  data  collected  in  the  system 
level  activity  must  be  converted  into  input  formats 
that  can  be  read  by  the  participating  federates.  These 
representations  may  be  databases,  spreadsheets,  XML 
files,  or  other  file  formats  required  by  the  participating 


Figure  8:  Sequence  diagram  for  simulation  functions  and  in¬ 
formation  exchanges  required  to  support  the  communicate 
function  of  the  ground  soldier  command  and  control  simu¬ 
lation. 

simulations.  In  some  cases,  supporting  tools  for  the 
simulation  can  ease  this  transition.  In  other  cases,  it  is  a 
laborious  manual  process  using  basic  editors. 

Build  data  collection  models  in  simulation  specific  formats. 

In  this  step,  the  data  collection  requirements  determined 
in  the  system  level  activity  must  be  represented  as 
output  data  from  simulation  federates  or  from  data 
loggers  tied  to  the  federation.  Depending  upon  the 
federate,  these  format  may  be  supported  by  standard 
database  systems,  or  they  may  simply  be  text  or  log 
files  that  must  be  processed.  The  developers  must  build 
queries  or  tools  that  collect  this  raw  data  and  summarize 
it  as  value  measures  from  the  value  model  built  in  the 
operational  level. 

Build  terrain  data  models  in  simulation  specific  formats 

The  source  terrain  data  must  also  be  converted  into 
simulation  specific  formats.  In  many  cases  commercial 
tools  support  this  process  for  a  variety  of  formats. 
In  other  cases,  the  terrain  data  may  be  read  into  the 
simulation  models  in  its  existing  geospatial  format.  The 
result  of  this  step  is  correlated  representation  of  the 
terrain  across  the  federation. 

4.3.  System  Development  and  Testing 

Delivery  of  the  engineering  products  described  at  each 
level  will  give  system  developers  all  of  the  specifications  they 


need  to  build  software  components  that  deliver  the  required 
functionality  and  interface  with  the  federation  architecture. 
The  operational  level  will  give  them  a  conceptual  context  for 
integration.  The  system  level  will  give  them  a  semantic  view 
of  their  components  and  an  understanding  of  the  overall  simu¬ 
lation  architecture.  Finally  the  technical  products  will  specify 
their  components  in  sufficient  detail  to  allow  them  to  interface 
with  the  selected  technical  infrastructure.  A  good  systems  en¬ 
gineering  process  requires  stakeholders  from  all  three  of  these 
levels  for  the  to  work  together  in  a  coordinated  way. 

Despite  the  best  intentions  of  a  well  designed  architecture, 
there  is  no  substitute  for  component  and  integration  testing  to 
ensure  all  of  the  pieces  work  as  advertised.  Component  tests 
are  designed  around  individual  components  and  their  inter¬ 
faces.  They  typically  test  a  discrete  function  by  replicating 
the  inputs  from  the  federation  and  reading  the  outputs  from 
the  federate.  The  ground  soldier  simulation  system  used  the 
Modeling  Architecture  for  Technology,  Research  and  Exper¬ 
imentation  (MATREX)  |T^  environment.  This  environment 
supported  automatic  test  case  generation  to  support  integra¬ 
tion.  Larger  scale  integration  tests  bring  together  a  number 
of  federates  and  test  the  ability  of  the  federation  to  model 
system-level  capabilities  and  to  collect  system-level  data. 

5.  ADVANTAGES  OF  A  SYSTEMS  ENGI¬ 
NEERING  APPROACH 

There  are  three  main  advantages  to  using  a  systems  engi¬ 
neering  approach  to  federated  simulation  development.  The 
first  advantage  is  to  ensure  a  clear  line  of  logic  from  oper¬ 
ational  representations,  to  system  level  federation  design,  to 
coding  and  development.  A  second  advantage  is  the  separa¬ 
tion  of  concerns  permitted  by  modeling  the  system  on  three 
different  levels.  Operational  experts  do  not  have  to  read  com¬ 
puter  code  to  adjust  models  on  the  operational  level.  System 
level  experts  can  organize  and  specify  the  system  using  sys¬ 
tems  architecture  tools,  and  code  developers  can  work  from 
technical  level  specifications.  The  final  advantage  is  that  all 
of  the  systems  engineering  products  support  the  engineering 
manager  in  implementation  of  the  development  and  test  plan. 
It  breaks  the  complex  federation  into  discrete  pieces  of  func¬ 
tionality  that  can  be  developed,  component  tested,  and  in¬ 
tegration  tested  in  order  to  manage  progress.  This  approach 
has  helped  during  implementation  of  the  ground  soldier  com¬ 
mand  and  control  federation,  saving  a  great  deal  of  develop¬ 
ment  tim  and  effort  that  is  typically  spent  rectifying  poorly 
specified  interfaces  during  integration  tests. 
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Figure  6:  Allocation  to  request  fires  functions  to  simulation  federates,  represented  as  vertical  swim  lanes. 
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System  of  Systems  Issues 

“Systems  of  systems  exist  when  there  is  a  presence  of  a  majority  of  the  following 
five  characteristics:  operational  and  managerial  independence, 
geographical  distribution,  emergent  behavior,  and  evolutionary 
development.”  [Sage  and  Cuppan  2001] 


♦  Air  space  management  and  safety  achieved  by  all  component  systems 
working  together 

♦  Individual  systems  provide  useful  services  (fire  power,  real  time  video) 

♦  Individual  systems  are  acquired  independently  with  different  contractors 

♦  Individual  systems  come  and  go  routinely 

♦  Dependent  on  networked  communications 

♦  Standard  protocols  and  interfaces 

♦  Geographically  dispersed 

♦  System  complexity  leads  to  emergent  behavior 

♦  Extensive  coordination  is  central  to  achieving  high  levels  of  efficiency  and 
safety 
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Why  Federate? 


♦  Analysis  or  performance  measurement  for 
overarching  system  measures 

♦  Considering  alternative  sub-systems  or 
architectures 

♦  Sub-system  models  available  for  reuse 

♦  Models  are  geographically  distributed 

♦  Building  a  single  model  of  a  large  complex  system 
is  difficult  and  costly 
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Information  Exchange  System 

The  capability  to  pass  meaningful  information  between 
federates  during  the  simulation  run. 

♦  Levels  of  conceptual  interoperability  (Turnitsa 
Tolk) 

♦  Interoperability  standards 

♦  Distributed  Interactive  Simulation 

♦  High  Level  Architecture 

♦  Web  Services 

♦  Interoperability  tools 

♦  UML  modeling 

♦  Data  modeling 

♦  Army’s  Modeling  Architectures  for  Technology,  Research  and 
Experimentation  (MATREX) 
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Environmental  Representation 

The  capability  for  federates  to  reference  a  shared  and 
correlated  environment  in  which  entities  interact. 

♦  Reference  a  conceptually  aligned  common 
environment  with  detail  appropriate  for  federate 

♦  Environmental  standards 

♦  Synthetic  Environment  Data  Representation  and  interchange 
Specification  (SEDRiS) 

♦  GIS  standards 

♦  Strategies 

♦  One  common  environmentai  database 

♦  Correlated  modeis  buiit  using  a  singie  tool 

♦  Correlated  models  build  using  different  tools 
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Entity  Representation 

The  capability  for  federates  to  referenced  shared  conceptually 
aligned  information  about  entities  in  the  simulation.  Some  of  this 
representation  is  passed  via  the  information  exchange  system. 


♦  Characteristics  that  do  not  change  during  the 
simulation  run 

♦  Data  typically  loaded  from  federate  specific  data  sets 

♦  Data  from  different  federates  must  be  conceptually  aligned  with  an 
authoritative  and  shared  source,  such  as  AMSAA  data 

♦  Dynamic  characteristics  that  make  up  the  entity 
state 

♦  state  is  dynamically  updated  based  on  simulation  events 

♦  Federates  access  entity  states  via  the  information  exchange 
system 
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Models 


Within  the  context  of  the  analysis  or  training  question,  the 
internal  models  of  each  federate  must  be  validated  and 
coordinated  across  the  federation. 


♦  Models  running  in  a  new  context 

♦  Model  must  be  appropriate  for  simulation 

♦  Example  -  High  energy  laser  modeling  to  defeat 
incoming  projectile 

♦  Model  validation  steps 

♦  Verify  model  assumptions  within  the  new  context 

♦  Run  the  federation  with  data  for  which  the  results  are  known  or  can 
be  expected  to  fall  within  a  certain  range 

♦  System  experts  can  view  simulation  runs  and  provide  face  validity 
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Data  Collection 

The  capability  to  collect  meaningful  information  from  the 
simulation  run  in  the  context  of  the  analysis  question  or  training 
objective  for  which  the  federation  was  designed. 

♦  What  is  the  question? 

♦  Define  question  in  terms  of  simulation  inputs  and 
outputs 

♦  Data  collection  sources 

♦  Data  collection  tools  for  individual  federates 

♦  Data  loggers  for  the  federation 

♦  Custom  data  collection  and  analysis  tools  for  a  specific  federation 

♦  Human  observation  and  measurement 
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Time  Management 

The  capability  to  execute  the  simulation  in  separate  federates 
in  a  synchronized  way  so  that  the  ordering  of  events  and 
interactions  between  entities  mirror  the  real  system. 

♦  Simulations  are  synchronous 

♦  Federates  must  have  a  shared  representation  of 
time 

♦  Synchronization  strategies 

♦  Execute  in  real  tinne 

♦  Use  a  multiple  of  real  time 

♦  Federation  maintains  a  clock  and  look-ahead  window 

♦  Federation  maintains  the  event  list 
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Model  Driven  Architectures 


Q\Si»te/ng 


Similar  system  engineering  view  like  captured  in 
DoDAF  (OV,  SV,  TV)  and  as  supported  by 
the  Military  Missions  and  Means 
Framework  (MMF) 

♦  Computer  Independent  Model  (CIM) 

♦  Operational  Idea,  high-level  view 

♦  Platform  Independent  Model  (PIM) 

♦  Algorithmic  Solutions 

♦  Identifies  classes,  associations,  etc. 

♦  Platform  Specific  Model  (PSM) 

♦  Code-level  solution 

♦  Platform  and  language  specific 

♦  All  models  are  connected  via 
transformation  patterns 
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AH64  Apache/UAS  Cooperative 
Engagements 

♦  Components 


♦  Deployable  Virtual  Training  Environment  -  Cobra  and  LIAS 

♦  Joint  Semi-Automated  Forces  (JSAF) 

♦  One  Semi-Automated  Forces  (OneSAF) 

♦  Joint  Live  Virtual  Constructive  Data  Translator  (JLVCDT) 


♦  Combination  of  HLA  and  DIS 

♦  Terrain  generated  with  Terra  Vista  tools 

♦  Entity  mappings  are  a  challenge 

♦  SAF  model  has  lower  fidelity  representation  of 
character  or  vehicle  actions 
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Soldier  Command  and  Control 


Components 

♦  One  Semi-Automated  Forces  (OneSAF)  or  COMBAT  XXI 

♦  Infantry  Warrior  Simulation  (IWARS) 

♦  MATREX  Battle  Command  Management  Services 

♦  Brigade  and  Below  Propagation  Protocol  Communications  Mode 


♦  HLA  integration  in  MATREX  architecture 

♦  All  models  use  OneSAF’s  Environmental  Runtime 
Component  (ERC) 

♦  IWARS  handles  high  fidelity  soldier  models 

♦  Entity  identification  is  a  challenge 

♦  Data  collection  using  MATREX  federation  logger 
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Swarming  Unmanned  Aircraft  Systems 


♦  Components 

♦  VR-Forces  SAF 

♦  Visualization  federate  (Mac-OS) 

♦  Swarming  control  federate 

♦  DIS  for  information  exchange 

♦  Direct  object  integration  for  C2 

♦  Terrain  representation  in  simulation  and  in  GIS 
format  for  C2 

♦  Custom  data  collection  federate  written 
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Systems  Engineering  Resuits 


♦  Operational  View 

♦  System  functions  to  be  simulated 

♦  Associated  metrics  to  be  collected  via  simulation 

♦  Operational  descriptions  of  scenario,  forces,  and  terrain 

♦  Systems  View 

♦  Allocation  of  system  functions  and  metrics  to  supporting  simulations 

♦  Simulation  functional  requirements 

♦  Simulation  terrain  and  entity  databases 

♦  Information  exchange  requirements  and  data  model 

♦  Technical  View 

♦  Support  for  integration  with  specific  interoperability  protocol 

♦  Automatically  generated  test  cases 
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